\textbf{Google Grups}
\textbf{mapsforge-map-writer memory usage.}
\begin{verbatim}
jo (Adrià Ribatallada)	
05/12/12

Hi.

I'm trying to run osmosis in an Android device to convert downloaded osm 
data to the mapsforge .map format, and store that to the device for 
latter use.

And after a lot of trouble I almost got it working.

I say almost, because in the emulator it does work, but it fails in all
the "real" devices I'v tested with an Out Of Memory Exception (so it's 
technically not working).

I'm only being able to perform the actions correctly in the android 
emulator because there I'v set a "Max VM application heap" to 132Mb. 

But all my devices have less than that, about 64Mb , and eventually got 
the OOM exception.

And it seems that where all fail is in the last stage of my osmosis 
pipeline, which is the stage where I perform the --mapfile-write.

I'v tried to force the option type=hd, with some problems, but at the 
end, even using that option the problem persists. And all seems to 
indicate that the largest memory consumption is when executing the 
map-writer plugin, so I don't think that's something that the osmosis-
dev team could help me solve. 

I don't know exactly if all that memory is strictly required, but it 
shocks me a little, because I'm working with very small osm data files,
so I'm wondering...

Is there a chance to do some improvement in that aspect in the 
map-writer plugin, or that a memory leak exists there and we can easily 
reduce that amount of memory consumed?

Here is a verbose output log of a crashed execution in the android 
device (I painted the more relevant osmosis output sections), in case 
you need more information don't hesitate to request it.

Thanks in advance for any help.

[...]

Atentament,

Adrià Ribatallada i Torelló.
\end{verbatim}

\textbf{Re:}
\begin{verbatim}
Jürgen Broß	
05/12/12

Hi Adrià, 

the map-file writer is intended to be executed on a rather large and 
powerful machine and is simply not suited to be run on a mobile device. 
It does some heavy computations and to speed this up, it generally 
trades memory requirements for gains in execution time. 

The available heap size for a single app on Android is generally 
artificially restricted to a certain amount. Unless you have a "rooted" 
device, you cannot adjust this artificial restriction. 

I'm curious about your use case. Why do you want to convert OSM data on 
a mobile device? 

Best regards, 
Jürgen 

Jürgen Broß 
Institute of Computer Science 
Databases and Information Systems 
Freie Universität Berlin 
Takustr. 9 
D-14195 Berlin, Germany 
phone: +49 30 838-75108 
email: juerge...@fu-berlin.de 
\end{verbatim}

\textbf{Re:}
\begin{verbatim}
Hi Jürgen,

Thanks for the quick response.

2012/12/5 Jürgen Broß <juergen.bross@fu-berlin.de>
Hi Adrià,

the map-file writer is intended to be executed on a rather large and
powerful machine and is simply not suited to be run on a mobile device.
It does some heavy computations and to speed this up, it generally
trades memory requirements for gains in execution time.

I see.

The available heap size for a single app on Android is generally
artificially restricted to a certain amount. Unless you have a "rooted"
device, you cannot adjust this artificial restriction.

I'm curious about your use case. Why do you want to convert OSM data on
a mobile device?

The issue is, we have an application to collect some geo-localized data,
and we wanted to easily download some parts of the map when available 
networks were present, and then when we were in the "field" collecting 
our data, we can use that offline maps, and synchronize the data later.

It was an... "ease of use" improvement considering having to process 
that data on a PC and then transferring that maps to the phone. And 
since the way that mapsforge handles the offline maps support is using 
the .map format and the way to generate that kind of files is using 
osmosis, and I didn't wanted to setup a server just for generating that 
maps... I figured that the processing might be performed on the mobile
device itself, I thought... why not?

Well, as you can see, the use case is rather simple, but maybe mine 
might not have been the best approach.

Apart from setting up a server that processes all the info, is there a 
way to achieve our goal?

Thanks.

Kind regards,
Adrià Ribatallada i Torelló.

\end{verbatim}
